Towards Open Electronic Commerce: Computer Aided Design of Electronic Trade Procedures

Global information infrastructures can offer tremendous opportunities for small and medium enterprises to do global business electronically. But communication networks alone are not sufficient to enable international electronic trade. Parties have to know about each others' "way of doing business" before they can start exchanging data electronically; they have to agree upon the trade procedure they are going to follow.The primary focus of this paper is thus the representation and modeling of electronic trade procedures. We introduce Documentary Petri Nets as the modeling representation, and present a CASE tool, called CASE/Open-EDI, as a graphical modeling and simulation environment for open electronic commerce. A complex example is shown of documentary credit operations. A secondary aspect of the paper addresses the multi-lingual aspects of international trade. CASE/Open-EDI also provides multi-lingual structured documents and multi-lingual text generation. An example scenario (of buying bicycles) is shown which includes English, Russian and Dutch. In the closing discussion we suggest other research issues in support of open electronic commerce among international parties. 1 . TOWARDS OPEN ELECTRONIC COMMERCE Electronic Document Interchange (EDI) can have tremendous benefits for the efficiency of trading both between and within organizations. On the other hand it can also been shown that in many cases long and costly negotiations are necessary between the trading partners before they can exchange their first EDI message. As a result, most successful EDI implementations have been realized in what could be called 'closed trading relationships', i.e. long-lasting trading relationships, involving a high number of transactions, between parties that have a high level of trust and possibly a close coordination of the parties' business processes.However, when the partnership is established for a limited period, covering a few transactions only and on an "at arms' length" basis, EDI linkages are seldom observed since the costs of the necessary negotiations cannot be recovered from the benefits. These shorter-term partnerships could be called 'open trading relationships' (Table 1). The main aim of our research is to contribute to the lowering of the barriers for using EDI in these open trading relationships. Open Closed Level of Trust Low High Number of Transactions Low High Duration of Relationship Short Long Level of Coordination Low High Table 1. Open vs. closed trading relationships. One of the main reasons for the complexity of the negotiation process is the fact that parties have to know about each others' "way of doing business" before they can start exchanging data electronically. Extra knowledge about the preferred way of doing business of one trading partner has to be conveyed to the other; in other words, the parties have to agree upon the trade procedure they are going to follow. We define a trade procedure as the mutually agreed upon set of rules that governs the activities of all parties involved in a set of related business transactions. Thus, a trade procedure controls all interactions among the roles involved. A trade procedure stipulates which actions should be undertaken by which parties, the order in which these actions should be performed and possibly the timing constraints on the performance of these actions. Actions of parties include the sending and/or receiving of goods, documents or funds. 2 MODELING ENVIRONMENT: CASE/OPEN-EDI The CASE/Open-EDI tool provides a direct manipulation graphics interface for designing contracting procedures. In actual commercial operation, this would be used by the contracting network administrators to design libraries of such procedures to guide the interactions of the contracting parties. In contracting, events may occur in a temporal sequence, with branching, reflecting choices in the sequence by the parties, or contingencies imposed by external events. As well, contracting procedures may have concurrent activities, e.g. the processing of payment documents while the goods are being shipped. Because of these requirements, we have chosen a Petri net representation (see e.g. Peterson, 1981) to model these temporal relationships. In its basic form, a Petri net is a directed graph with two kinds of nodes: 'place' nodes, drawn as circles, and 'transition' nodes, drawn as a bar (either vertical or horizontal). The place nodes indicate the potential static states of the system. During the execution of a Petri net, a place node is marked as active by drawing a token in it. typically these are drawn as dots within the circle, though in our model they are shown as a bold outline of the node. Transition nodes represent the potential events of the system. A transition node is enabled when all its input places have tokens. In this case, the transition may 'fire', removing tokens from its input places and depositing new tokens in each of its output places. Branching, or choice in the sequence of activities, is indicated by multiple arcs emanating from a place node. Concurrency, where several activities may occur at the same time, in indicated by multiple arcs emanating from a transition node. In order to capture the semantic details of contracting, we have augmented the Petri net notation in two ways. Most importantly, each transition node is labeled with an 'action' predicate that must (also) be true for the transition to fire. We have also found it necessary to augment the notation for places. Optionally, a place may have a predicate label, indicating the condition that holds when it is active. Also, some places may have the special interpretation as documents (or data stores), in which case we draw them as a rectangle. The resulting extended Petri net has similarities to the predicate/transition nets of Genrich and Lautenbach (1981).This extended Petri net notation is supported by a special graphical interface, illustrated as follows: Figure 1: Interactive Graphical Interface for CASE/Open-EDI The upper left hand area is a tool palette, where the user selects drawing tools. Using a mouse, one selects, for instance, a place node or transition node tools and clicks in the drawing area (on the right) at the desired location. Using the arc tool (bent arrow), one draws the connecting arcs. Using the select (large arrow), eraser (block) or attribute ('#') tools, one may move, delete or modify the attributes on the graph. It should be noted that this is not simply a documentation facility, such as MacDraw. Rather, the graphical structure is understood by the system and may be executed in simulation fashion. 3. A SCENARIO: INTERNATIONAL DOCUMENTARY CREDITS Commonly, payments in international sales contracts are executed by a documentary credits procedure, subject to the rules set forth in the Uniform Customs and Practice for Documentary Credits (ICC 1983). Documents play an important role in these transactions in that payment for the goods is made not on the delivery of the goods themselves but on the presentation of stipulated documents. Stipulated documents may include a commercial invoice, an insurance certificate, a certificate of origin, and a transport document (e.g., a bill of lading or an airway bill), among others. The seller receives payment by presenting the stipulated documents to a bank (the advising bank) that the buyer has instructed to make payment. Two attributes make documentary credit procedures in international sales contracts a challenging example problem domain for modeling electronic trade procedures. First, these procedures involve numerous agents (who often must interact in disparate languages). The agents in an international sale using documentary credits may include two or three banks, a forwarder/broker, a liner-agent, a land transport carrier, a customs official, an insurance agent, a stevedore (to load the goods on the ship), a ship's captain, and several others in addition to the buyer and seller. Second, these procedures are mired in bureaucratic complexity and are subject to a host of confusing rules depending on the countries of the exporting/importing parties. At one time as many as 100 forms (i.e., performative communications) were required to ship goods from one country to another and to arrange payment (Bergsten 1985). The task of processing these myriad forms was so cumbersome that the goods commonly travelled faster than the forms, arriving before the documents did (Kindred 1988). The documentary credit procedure is fully governed by the exchange of paper documents among the parties involved. The purpose of these papers is to provide evidence that a party has performed its part of the deal specified in the underlying sales contract. Since the banks involved make profound checks on the documents they are presented by the shipper the buyer can be sure of the shipper’s performance of the sales contract. On the other hand, since the banks are obliged to pay upon receipt of correct documents under the documentary credit procedure, the seller can be sure that if he performs according to the sales contract he will always be paid. Using the original sales contract, the buyer enters a contract with a bank in his country, the issuing bank.. This results in a Letter of Credit, in which the buyer specifies which documents the seller has to present to evidence his performance. Of course, this performance should conform to the original sales contract. For instance, if the buyer wants to check whether the seller actually shipped the goods, he usually requires an original Bill of Lading, Waybill or another equivalent document for that purpose. In this example, we assume that the Bill of Lading is the only document required; in practice a commercial invoice, packing list, a certificate of origin and several other documents are usually required. For our discussion on the edification of such documents it suffices to deal with the Bill of Lading since this document encapsulates all possible aspects of performative negotiable documents. The issuing bank contacts a bank in the seller's country to become the corresponding bank. If this bank agrees to become the corresponding bank, it will forward the Letter of Credit to the seller (the shipper of the goods). The corresponding bank advises the shipper on the feasibility of the terms and conditions in the Letter of Credit. This may lead to modifications of the Letter of Credit. Of course, these modifications will have to be made in mutual agreement between the buyer, seller and the banks involved. As soon as the Letter of Credit is agreed upon, the seller is obliged to "produce" the documents evidencing the performance of his part of the sales-contract. The Letter of Credit exactly specifies which documents should be presented. The corresponding bank can advise the shipper how this should be best done. The corresponding bank has the task to validate the documents presented by the shipper against the Letter of Credit If they are in accordance the corresponding bank forwards them to the issuing bank. In many cases, the corresponding bank will pay the seller in advance upon the acceptance of his documents. Depending on the type of documentary credit this payment is conditional or unconditional. If the seller is not a regular client of the corresponding bank this bank may contact yet another bank to transfer the money to the seller’s account. Issuing Bank Corresponding Bank